Skip to main content

AKS Private com Custom DNS Server

· 5 min read
Felipe Schulz
Cloud Architect

Ao criar uma rede no Azure, por padrão os servidores DNS são gerenciados pela própria plataforma. Porém em alguns casos, você talvez queira utilizar os seus próprios servidores DNS, para resolver nomes, ter um maior controle ou por ter replicação de DNS tanto no Azure, como no seu ambiente on-premises ou outra Cloud para conferir uma maior redundância.

Mas pode ser você tenha problemas com alguns recursos do Azure, que precisam se comunicar com os servidores padrões DNS da rede virtual, ou enviar alguma telemetria (como heartbeat) para a plataforma, para que funcione como o esperado.

No caso em particular do AKS, ele se comunica com um IP bem especifico da plataforma (o IP 168.63.129.16) para que o API Server consiga resolver os nomes através de uma Private DNS Zone e garantir que as comunicações dentro do cluster permaneçam seguras e privadas, sem expor seu cluster a internet (também há um recurso adicional que pode incrementar isso, vamos comentar sobre no final desse conteúdo, como bônus). Quando esse IP em particular está inacessível, você provavelmente verá uma tela com erros semelhantes a este:

Agents are unable to resolve Kubernetes API server name

Cluster em estado "Failed"

Status no VMSS (que compõe o nodepool) fica com erro ProvisioningState/failed/VMExtensionProvisioningError

VMSS Failed

Mas o que é o IP 168.63.129.16?

Esse IP é importante também para comunicar o status de provisionamento de VMs (ou seja, dos nodes do seu cluster), health probes de Load Balacers, obter um IP dinâmico do serviço de DHCP em uma rede virtual e permitir as mensagens e monitoramento dos Agentes de serviços PaaS.

Esse IP é bem importante no Azure, ele é usado em todas as regiões do Azure e não se altera com o tempo. Portanto configure suas regras de firewall (se aplicável) para permitir a comunicação de saída com esse IP, senão um monte de coisas no Azure podem não funcionar como o esperado. Ele não retorna consultas de DNS lookup, então um nslookup ou dig não vai retornar nada (mas acredite, ele funciona). Ele é o equivalente do "42" da pergunta fundamental da vida, o universo e tudo mais 😊

Caso queira saber mais, consulte essa documentação: What is IP address 168.63.129.16? | Microsoft Learn

Mas ok, o que acontece então se eu tenho servidores DNS personalizados configurados na minha rede virtual, e tentar fazer o deploy de um cluster AKS ? A resposta curta é: ele vai "nascer" quebrado.

Considere o seguinte cenário:

Diagrama Lab

Então nós temos aqui um servidor de DNS, que foi configurado lá rede virtual como DNS server primário:

Custom DNS VNet

E vamos fazer o deploy de um cluster privado nessa mesma rede virtual, mas na subnet chamada "snet-aks", e vamos selecionar a opção de usar nossa própria rede, por marcar a caixa "Bring your own Azure virtual network" e selecionar a respectiva vnet e subnet:

Bring your Own VNet

Após alguns minutos de deploy, provavelmente você terá o problema mencionado:

Deployment Failed

Como contornar esse problema para que o seu cluster não quebre no deploy?

No seu servidor DNS, inclua o IP 168.63.129.16 como Forwarder, e certifique-se que ele seja o primeiro DNS Server da lista (não adicione como conditional forwarder):

Forwarder in DNS Server

Caso você queira recuperar o cluster anteriormente (que nasceu quebrado), você poderá usar o seguinte comando:

az resource update --resource-group <resource-group-name> --name <cluster-name> --namespace Microsoft.ContainerService --resource-type ManagedClusters

Ou pelo portal, clique no botão "Retry" que ele irá reconciliar o estado do cluster:

Reconcile cluster

Após alguns minutos, o seu cluster conseguirá resolver as consultas de DNS, através do Forwarder configurado, e o seu cluster está operacional:

Cluster running

Agora é só correr pro abraço 🎉


Bônus: Desabilite o FQDN público do seu cluster, por usar a flag --disable-public-fqdn

Ao desabilitar o FQDN público, você reduz a superfície de ataque do cluster, tornando-o menos suscetível a acessos não autorizados e ataques externos. Muitas organizações têm requisitos de conformidade que exigem que os recursos de TI sejam acessíveis apenas por meio de redes privadas. Desabilitar o FQDN público ajuda a atender a esses requisito.

Ao consultar com nslookup o FQDN do, ele trará o IP privado do seu cluster:

FQDN Público

Ao desabilitar esse FQDN, o API Server Address passa a ser privado também, e assim não será alcançável externamente mais:

FQDN Privado

Caso já tenha criado o seu cluster e queira desabilitar o FQDN público, use o seguinte comando: az aks update \ --name <private-cluster-name> \ --resource-group <private-cluster-resource-group> \ --disable-public-fqdn

Saiba mais em Criar um cluster de Serviço de Kubernetes do Azure (AKS) privado - Azure Kubernetes Service | Microsoft Learn

Material Adicional

Caso queira reproduzir o laboratório, seguem os links que poderão ajudar a reproduzir o cenário descrito:

AKS private cluster with custom DNS Server.sh

Referências adicionais

Troubleshoot the K8SAPIServerDNSLookupFailVMExtensionError error code (52) - Azure | Microsoft Learn

Create a private Azure Kubernetes Service (AKS) cluster - Azure Kubernetes Service - Basic Networking | Microsoft Learn

Create a private Azure Kubernetes Service (AKS) cluster - Azure Kubernetes Service | Microsoft Learn